An application program interface (API) for a network platform can be used by developers to build Web applications and services. One such API is the NET™ platform created by Microsoft Corporation of Redmond, Wash., USA. The NET™ platform is a software platform for Web services and Web applications implemented in a distributed computing environment. The .NET™ platform allows integration of a wide range of services that can be tailored to the needs of the user. As used herein, the phrase application program interface or API includes traditional interfaces that employ method or function calls, as well as remote calls (e.g., a proxy, stub relationship) and SOAP/XML invocations. The .NET™ platform uses a framework that includes the ‘Common Language Runtime’ (CLR). Additional information regarding the basics of the .NET™ Framework can be found in a number of introductory texts, such as Pratt, Introducing Microsoft .NET, Third Edition, Microsoft Press, 2003.
The CLR is the heart of the Microsoft NET™ Framework and provides the execution environment for all NET code. Thus, code that is built to make use of the CLR, and that runs within the CLR, is referred to as “managed code.” The CLR provides various functions and services required for program execution, including just-in-time (JIT) compilation, allocating and managing memory, enforcing type safety, exception handling, thread management and security. The CLR is loaded upon the first invocation of a .NET™ routine. Because managed code compiles to native code prior to execution, significant performance increases can be realized in some scenarios. Managed code uses Code Access Security (CAS) to prevent assemblies from performing certain operations.
When writing managed code, the deployment unit is called an assembly which is a collection of one or more files that are versioned and deployed as a unit. An assembly is the primary building block of a NET™ Framework application. All managed types and resources are contained within an assembly and are marked either as accessible only within the assembly or as accessible from code in other assemblies. An assembly is packaged as a dynamic link library (DLL) or executable (EXE) file. While an executable can run on its own, a DLL must be hosted in an existing application.
Within any host, access rights for calls between assemblies should be defined and limited via security rules to prevent malicious code from causing problems. An example of an environment in which a host should intervene upon the occurrence of a call from one assembly to another is in the case of a cellular telephone (cell phone) that is ‘.NET’ enabled. Being NET enabled, the cell phone can run managed code. It would be desirable to configure the cell phone to enforce a rule that any cell phone application can talk to the cell phone platform assemblies that are provided as common cell phone services to any cell phone application. This rule may also enforce a provision that no cell phone application can call any another cell phone application. As such, the rule requires that cell phone applications are to be treated as complete sandboxes. By trapping cross assembly calls, cross assembly calls are prevented from one cell phone application assembly to another cell phone application assembly until a call back has been made back to the platform assembly for common cell phone services to verify permissions for the call. Example cell phone applications are a billing application and a ring or tone application. Suppose that a tone application has been downloaded by one cell phone and contains malicious code. The user of the cell phone which has the malicious code shares the tone application among several different cell phone users. In this case, the malicious code can stage an attack by using an assembly to call into an assembly of the billing application of one of the cell phones to which the tone application was shared. Once the calling assembly with the malicious code has gained access to the callee assembly in the billing application, the assembly with the malicious code in the tone application can make illegal charges against that user's cell phone billing account. Accordingly, it would be an advance in the art to provide cross assembly call interception that allows calls from one application to be made into common platform services, but that prohibits an application from interfering with the execution of any other application.
Another example of a host is a server that hosts an object-oriented database, where the server has a security model that is user identity based. In contrast, the security model for the CLR bases access rights to a protected resource on Code Access Security (CAS), not on user identity. Managed assemblies registered with the host server are server objects from the host's perspective. Access rights for these server objects can be defined and limited via security rules defined for individual user identities or roles. Host servers therefore must be given a way to allow or disallow access from one managed assembly to another based on the host server's user identity based access rules. It would be an advance in the art to provide a way that allows host servers to allow or disallow access from one managed assembly to another (cross-assembly calls) based on the host server's user identity based access rules, where such cross-assembly calls meet both CAS permission demands as well as user ID permissions governing access from one server object to another.